home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20010921-20020314
/
000245_robert@bonomi.invalid_Sat Dec 15 13:21:05 EST 2001.msg
< prev
next >
Wrap
Text File
|
2002-03-13
|
6KB
|
126 lines
Article: 13070 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!panix!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!cpk-news-hub1.bbnplanet.com!news.gtei.net!newsfeed.cwix.com!feed.news.qwest.net!news.uswest.net.POSTED!not-for-mail
Newsgroups: comp.protocols.kermit.misc
References: <9vb3i1$989$1@watsol.cc.columbia.edu>
Sender: robert@bonomi.invalid
From: robert@bonomi.invalid
Originator: robert@bonomi.invalid
Organization: Robert Bonomi Consulting
Subject: Re: C-Kermit 8.0 files/installation?
X-Newsreader: trn 4.0-test69 (20 September 1998)
Originator: bonomi@news2.bonomi.com (Robert Bonomi)
Lines: 106
Message-ID: <N%LS7.255$fb1.172478@news.uswest.net>
Date: Sat, 15 Dec 2001 17:46:21 GMT
NNTP-Posting-Host: 168.103.248.65
X-Trace: news.uswest.net 1008438381 168.103.248.65 (Sat, 15 Dec 2001 11:46:21 CST)
NNTP-Posting-Date: Sat, 15 Dec 2001 11:46:21 CST
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13070
[ reply note: I'm not an invalid, but a dot-com ]
In article <9vb3i1$989$1@watsol.cc.columbia.edu>,
Frank da Cruz <fdc@columbia.edu> wrote:
>
>I'm still in a quandary about how to package C-Kermit 8.0.
>Previously it came with all sorts of .ini, .txt, and other files,
>which few people wanted or knew what to do with.
>
>In C-Kermit 8.0, the initialization file is probably unnecessary
>for most people, and the *.txt files have been converted to HTML
>and put up on the Kermit website.
Comment: Documentation in HTML is nice, "pretty", makes it easy to cross-
reference things. All good reasons for using it.
*HOWEVER*, please don't make it the _only_ form that things are
available in! Sometimes a web-browser is *NOT* 'conveniently
available'. "Plain text" is *universally* readable with simple
tools, and can be much faster to use to find specific info. e.g.,
vi and a '/' search, will have the job done, _before_ a browser
finishes initializing itself.
>
>Thus, if you download C-Kermit (in some form) from the net, you
>can probably also consult the web pages the same way, rather than
>installing plain-text versions of them on your computer and
>putting them somewhere that nobody can find.
As an alternative, consider what Hylafax does -- it provides for customizations
in the Makefile as for where to install the configuration files and secondary
documentation. the makefile target for installing the manpages includes editing
to indicate the _actual_ locations on the installed system.
>
>Furthermore, we want the tarball and zip archives to be as small
>as possible. If we include all sorts of extra files in them,
>they will take much longer to download (e.g. on 56Kb connections)
>and most people will be annoyed when they find out why. Separating
>into separate taballs for text files and program files, as we have
>done in the past, is confusing too.
This is indicative of a 'documentation failure', not a flaw in the approach.
And much easier to remedy. Appropriate language in the release announcement
and the 'download' web-page -- e.g. "downloading the Supplement is _not_
necessary for a working Kermit installation"
>I'm beginning to convince myself that there is no reason why the
>Unix C-Kermit 8.0 tarball should include anything but the source
>code, the license, the manual page, and a brief read-me.
There are a few other 'necessaries', too. see below.
> All the
>other stuff is just confusing -- people tend to think they NEED to
>install those files or else C-Kermit won't work, which isn't true;
>the executable does its job just fine without any external files
>at all, and now that its default settings (e.g. file-transfer
>performance tuning, 8-bit-cleanliness, etc) are in tune with
>modern times, there is little need for anything but the binary
>itself, except when users want to do their own customizations.
>
>Thus the Unix "make install" target can be radically simplified,
>as can the construction of install packages like RPMs.
Absolutely. at most it should have a 'hook' to an _external_ "make install"
for the Supplement
>
>Meanwhile, people who are not on the network and who order
>C-Kermit on CDROM or tape or whatever will get everything, so
>no worries.
>
>Opinions?
Suggest, despite your prior 'confusion' experience, multiple tarballs.
The first one ("core distribution"):
README
INSTALL
license
source-code
manpage
changes (aka "whats new") [ by version, *cumulative*, not just
'new with this version')
known bugs/problems this version (a la the BWR files)
Then, there's going to be a bunch of documentation, etc. that is *not*
'platform-specific', and not essential to proper program operation.
put that in a second tarball (the "supplement").
Lastly, there are things that _are_ platform-specific, e.g. MVS and 7171
front-end mapping issues, VAX-isms, etc. Make a tarball _per_
_platform_ of this stuff. (the 'platform-specific' "Appendix")
A "binary" distribution could then consist of:
README
INSTALL (for binaries)
License
executable(s) and req'd support files (if any)
manpage
changes
known bugs
the O/S-specific "Appendix" (as a "tarball in a tarball" -- the
"installer" routine needs to know *only* how to unpack the tarball,
and _invoke_ the 'make install' (or equivalent) contained therein.)